1. Technical Field
This invention addresses the problem of accessing a remote data repository, hereafter called a database management system (or DBMS), from an application program which is executing in a different computer than the DBMS.
2. Description of the Prior Art
Data repositories, or DBMSs, store information which can be used in many ways to manage, control, analyze, model, track, and document a wide variety of real work activities in business, commerce, science, and government. The information stored in DBMSs can be shared by various application programs which exploit the information for specific purposes. Because it is very difficult to maintain the same information in different DBMSs on different computers, it is important that application programs be able to access and manipulate needed information wherever it resides.
However, application programs must not only access and manipulate information in DBMSs, but also interact with humans via computer displays and keyboards. This interaction is greatly facilitated if the application program can execute on a computer which is physically near to the human. It is also sometimes the case that an application program developed and adapted to a specific computer environment defined by language, operating system, or computer may need to exploit data in, or the special features of, a DBMS which is adapted to (and runs on) a different computer environment. Therefore, it would be useful for application programs to be able to access and manipulate information in a DBMS which is located at a different computer than the computer of the application program.
Another aspect of maintenance of information in DBMSs is that there are many differently implemented DBMSs whose database commands are specialized to particular computing environments or data models. An important class of differently implemented DBMSs are those known as relation database systems. Within this class are those DBMSs whose database command language is known as SQL. C. J. Date in his book entitled "AN INTRODUCTION TO DATABASE SYSTEMS", Vol. 1, Addison-Wesley (4th Edition, 1986), describes in Chapter 2 a relational database system which is based on the SQL database command language. However, even within this restricted class of DBMSs, there are differences in the SQL commands which different implementations can accept and process. These differences in the SLQ database command language reflect the different operating environments of different implementation as well as differences in the language functions supported.
Application programs which exploit DBMSs supporting the SQL database command language are written in any one of several different programming languages. SQL database commands to access the DBMSs data are embedded in the programs of the applications. Application programs are prepared for execution in several steps. First a component of a Application Access Agent called the SQL Preprocessor examines the text of the application program and replaces embedded SQL database commands with calls to another component of the Application Access Agent called the Database Interface Functions. These Database Interface Functions mediate the actual interactions with the DBMSs to effect the execution of the SQL database commands. Next, the modified application program is processed by a language compiler which translates it into a machine dependent sequence of computer instructions. Finally, the translated application program is combined (or linked) with the Database Interface Functions to produce a module which can be invoked and executed in a specific computing environment.
In addition to replacing the SQL database commands embedded in an application program with calls to Database Interface Functions, some SQL Preprocessor systems and SQL DBMSs support the ability to analyze and prepare SQL database commands for execution well in advance of the need to perform the commands during execution of the linked application program. This preparation for database command execution, known as binding, significantly improves application program performance. This is because analysis of SQL database commands generally entails relatively costly I/O operations to compare the names of database objects (e.g., tables, columns, etc.) found in the commands to the names of objects present in the particular DBMS. In addition, for many SQL database commands, the determination of the best sequence of database steps necessary to perform the command entails consideration of a, possibly, large number of alternative sequences. Choosing the best sequence of steps is known as optimization. Once analysis and optimization have been completed, the DBMS can retain the result and use it whenever execution of the corresponding SQL database command is required.
The problem addressed by this invention is the provision of a mechanism and procedure by which application programs executing on one computer can exploit the full services of a DBMS running on a different computer with a, possibly, different computer environment. The invention specifically addresses exploitation of evolving and idiosyncratic features of the database command language of different implementations of the remote DBMSs. This tolerance of database command idiosyncrasies is achieved using a single embodiment (implementation) of the Application Access Agent programs, coupled via a communication protocol to the DBMSs in remote computers. The invention also achieves enhanced performance by supporting binding of database commands in advance of execution of the application program.
Alternative mechanisms addressing these goals include:
1. a (local) DBMS at the application program computer which is capable of interacting with other, remote DBMSs to perform database commands at those DBMSs (i.e., a distributed database system);
2. remote execution of the database calls which could have been made to a local DBMS implementation using a Remote Procedure Call (RPC) mechanism;
3. a program on the application program computer which accepts, analyses, and optimizes database commands and sends (communicates) the resulting sequence of database steps to the remote DBMS for immediate or deferred execution;
4. communicating the database commands of the application program to a program (or device) at the remote computer of the DBMS which issues the database commands to its (now local) DBMS on behalf of the (now remote) application program; and
5. the Remote Database Access (RDA) communication protocol under consideration by national and international standards bodies.
The first alternative above requires advanced database function which is not available in most DBMS implementations. In addition, it requires that such a DBMS be present at the application program computer. This might entail significant cost for licenses, maintenance, and resources (CPU and storage).
Because database call interfaces are usually specific to a DBMS implementation and its computing environment, the second alternative above would require special support at the application program computer for each differently implemented remote DBMS. This multiplicity of support for specific DBMS call interfaces is costly to develop and must be extended whenever new remote DBMS implementations become available.
The third alternative above is extremely sensitive both to the kinds of database steps used at the remote DBMS and to the database command language features and functions supported by the program at the application program which computes the needed steps. Furthermore, functional enhancements to the database command language of the remote DBMS must be matched by similar enhancements to the Application Access Agent.
The fourth alternative above cannot analyze and prepare database commands prior to execution because the database commands of the application program are not presented to the remote DBMS prior to the execution of the application program on the application program's computer.
The fifth alternative above (RDA), also does not support analysis and processing of database commands prior to the execution of the application program which invokes the execution of the database commands. This leads to (possibly) significant performance penalties and does not allow amortization of the cost of analyzing and optimizing database commands over multiple executions of the application program.